1. Field of the Invention
The present invention relates to communication networks and, more particularly, to a method and apparatus for learning endpoint addresses of IPSec VPN tunnels.
2. Description of the Related Art
Data communication networks may include various computers, servers, nodes, routers, switches, bridges, hubs, proxies, and other network devices coupled together and configured to pass data to one another. These devices will be referred to herein as “network elements.” Data is communicated through the data communication network by passing protocol data units, such as data frames, packets, cells, or segments, between the network elements by utilizing one or more communication links. A particular protocol data unit may be handled by multiple network elements and cross multiple communication links as it travels between its source and its destination over the network.
The various network elements on the communication network communicate with each other using predefined sets of rules, referred to herein as protocols. Different protocols are used to govern different aspects of the communication, such as how signals should be formed for transmission between network elements, various aspects of what the protocol data units should look like, how packets should be handled or routed through the network by the network elements, and how information associated with routing information should be exchanged between the network elements. Two networks with the same network topography may operate in completely different ways depending on the particular protocols selected to enable the network elements to interoperate.
FIG. 1 illustrates an example communication network 10 in which VPN tunnels may be established to interconnect CEs connected to one or more VPN sites. As shown in FIG. 1a service provider provides interconnectivity amongst Customer Edge (CE) network elements 12. A CE device 12 is a device which connects one or more VPN sites 14 to a Provider Edge node 16. Essentially, a CE device allows one or more VPN sites to interconnect with an external network so that one or more VPN sites may be interconnected over the communication network 10.
A Provider Edge (PE) node is a router which connects to one or more CE devices using a dynamic routing protocol to exchange CE reachability information. The PE connects with at least one other PE or P node. When handling Internet Protocol (IP) MultiProtocol Label Switched (MPLS) traffic, a PE node acts as a Label Edge Router which terminates Label Switched Path (LSP) tunnels used to forward traffic to other PE nodes. PE nodes may be directly connected to other PE nodes, or may be connected through other network elements such as backbone routers 18.
Backbone routers 18 are commonly designated in the industry by the letter P. The Provider “P” routers are backbone routers which provide interior gateway protocol connectivity between PE nodes. It may be possible for a given router to act as a PE node for some VPNs and as a P router for other VPNs, however, depending on the configuration of the communication network.
A Virtual Private Network (VPN) may be formed by securing communications between two or more networks or network elements to form a VPN tunnel, such as by encrypting or encapsulating transmissions between the networks or network elements. Using VPN tunnels enables geographically dispersed VPN sites to exchange information securely without obtaining dedicated resources through the network.
There are several common ways of establishing VPN tunnels on a network. For example, VPNs may be established by customers through the deployment of CE network elements configured with VPN software. One common way to implement a CE-based VPN is through the use of Internet Protocol Security (IPSec) tunnels through the communication network. IPSec based VPNs use point-to-point IPSec tunnels formed using an IPSec Security Association (SA) between every pair of sites. As the number of sites in the VPN grow, this point-to-point solution does not scale, since the number of SAs required to implement the VPN will increase on the order on n2. To overcome this, it is possible to use a single SA for all sites in the VPN, for example administered via a Group Controller Key Server (GCKS).
Another way of establishing VPNs is to configure the VPN at the Provider Edge (PE) network elements to allow the service provider to provision VPN services on behalf of the customer. One common way to do this is described in Internet Engineering Task Force (IETF) Request For Comments (RFC) 2547, the content of which is hereby incorporated herein by reference. RFC 2547 describes a VPN architecture in which MultiProtocol Label Switching (MPLS)-based tunnels are used to forward packets over the network backbone. A protocol referred to as Border Gateway Protocol (BGP) is used to distribute routes over the backbone for VPNs provisioned through a particular PE network element. Routing information for the Provider-Provisioned VPNs is stored in a VPN routing and forwarding table (VRF) or a distinguishable area of the PE's common VRF.
In a CE-based VPN, to enable devices on one VPN site to communicate with devices on another VPN site via an IPSec VPN tunnel, it is necessary to exchange VPN routing information between the two CEs connected to the VPN sites. The routing information enables the CEs to learn which VPN addresses may be reached via the VPN. As VPN sites and network elements are added and removed from the networks, the new routing information will be advertised to the other CEs connected to participating sites in the VPN.
Where Multiprotocol Border Gateway Protocol (MPBGP) is being used to distribute VPN routing information, a given CE will establish an MPBGP peering session with every other CE with which it would like to exchange routing information. Where there are many CEs in the VPN, the GCKS may also serve as a route reflector to enable BGP routes to be exchanged between the various CEs by causing each CE to establish a single peering session with the route reflector, which will then distribute the routes to the other CEs.
When a CE learns a VPN route from an attached VPN site, it will formulate an MPBGP route advertisement so that the new route may be advertised to CEs connected to the other VPN sites associated with that VPN. The route advertisement will include the CE's MPBGP peering point address as the BGP-nexthop field in the route update, so that any traffic destined to this route will be sent to the CE as the next-hop.
Although MPBGP will cause the MPBGP endpoint addresses to be distributed, the MPBGP peering endpoint is not able to be used as the endpoint of an IPSec tunnel. The reason for this is that if the destination IP address of the MPBGP packet is the same as the tunnel endpoint address, this MPBGP packet will not get encrypted, since the only packets that are supposed to have a destination IP address of the tunnel endpoint are already encrypted packets, and we don't want to encrypt them again. This is the classic recursive encryption problem. Hence application packets that are candidates for encryption typically need to have destination IP address beyond the IPSec tunnel endpoint.
Thus, where IPSec is used to implement the VPN tunnels between CE network elements, and MPBGP is to be used as a routing protocol for exchange of VPN routes, the IPSec tunnel endpoints must also be distributed to the other CEs, so that the CEs may address encrypted traffic to the correct IPSec tunnel endpoints for the VPN routes.
There are several ways in which the IPSec tunnel endpoints may be learned by CEs. For example, a user may manually configure all IPSec tunnel endpoints on every CE. While this will work for small numbers of CEs, this solution is not scalable and may be difficult to implement or administer for large number of CEs.
Another way for CEs to learn IPSec tunnel endpoints may be for the GCKS to maintain a complete list of the IPSec tunnel endpoints for all CEs connected to sites in the VPN. When a new VPN joins the CE, and registers with the GCKS, the GCKS could then transmit a complete list of the fPSec tunnel endpoints for all other CEs. One downside to this is that it is necessary for the GCKS to maintain and update the VPN membership lists with this additional piece of information.
Another way to enable CEs to learn of IPSec tunnel endpoints of the other CEs is to define a new BGP Subsequence Address Family Identifier (SAFI) (see IETF RFC 2858) that may be used to specifically communicate the association of the IPSec tunnel endpoint with the MPBGP peering point on any given CE, to all other CEs. Although this would enable the CEs to communicate the IPSec tunnel endpoints directly with each other, doing so would require the MPBGP code to be enhanced to include this new SAFI functionality.
Yet another way to enable a CE to learn the IPSec tunnel endpoints of the other CEs is to use Next Hop Resolution Protocol (NHRP) to dynamically determine the tunnel endpoint addresses. The arrival of a first packet to a VPN destination at a CE would trigger the CE to use NHRP to determine the tunnel endpoint address that should be used to forward traffic on the route. Although this overcomes the problems associated with having the GCKS maintain a list of IPSec tunnel endpoint addresses, the amount of time required to dynamically determine the tunnel endpoint addresses may cause the first several packets to be dropped by the CE.